Data Intake File Processing Details

A File is particular to a single Group Customer. The particular way that a file is processed in the system is defined through the Intake Profile Definition, which is configured in the Rules Palette. The user has the opportunity to tailor the intake profile definition when an Intake Profile is created in the application. When creating an Intake Profile, the user can set thresholds, record field constraints, and other data that are used by OIPA during file processing.

Load File

A File is loaded into OIPA from the insurance carrier's file receiving system. In an implementation an OIPA Bridge will be created as part of the process that will translate messages coming in from the insurance carrier's file receiving system into appropriate API calls. For example, a "Start File" message might translate into a "Begin Loading" API call in OIPA. The file level information, and record level information, are sent to OIPA from the insurance carrier's file receiving system while the file is loading. To complete loading, file receiving system will send an indicator that the file is done, the file will go into a Pending status in OIPA.

The file is triggered to process by an explicit signal that is sent by the insurance carrier's file receiving system, or through an API call made by the OIPA Bridge. The details of the exact mechanism to trigger processing are outside of the scope of this document.

The following features pertain to loading a file into OIPA.

1. OIPA will provide a suitable extension mechanism to allow code to be written to receive messages from a message queue and call API methods. This extension mechanism will be used by the OIPA Bridge referred to in this document.
2. Files that fail in the insurance carrier's file receiving system will be recorded OIPA. OIPA will simply store the file header, error information, and any other relevant information in OIPA.
   1. OIPA will not allow a file that failed in the insurance carrier's file receiving system to be processed or reversed.
   2. OIPA will not capture any records for a file that failed in the insurance carrier's file receiving system.
   3. The failed file and related details that were captured in OIPA will be visible in the Intake File screen.
3. OIPA will support dynamic fields configured at the File level defined in the Intake Profile Definition. This will allow any field to be set when the file is sent to OIPA.
   1. These fields can be used to capture the insurance carrier's file receiving system's statistics, like existing records with fatal errors.
   2. These fields will be visible in the Intake File screen.
4. Warnings for records that are generated in the insurance carrier's file receiving system will be able to be captured in OIPA.
   1. These warnings will be visible in the OIPA application.
   2. These warnings will be available for reporting, as well as for processing the record.
5. While a file is loading, the file cannot be reversed.
6. Each Family Neutral Record sent to OIPA consists of one or more member records pertaining to either the sponsor for the FNR, or a dependent of the sponsor.
   1. Each record in an FNR has a prescribed order for which they should be processed.

Calculate Missing Records

The second step in processing a file is to calculate missing records. This step is only executed if it is configured in the Intake Profile Definition that the file is using for processing.

Missing records are calculated by examining records at the Sponsor (FNR) level. OIPA will look up all of the FNRs that have ever been received (but have not been removed) for a particular Group Customer and Intake Profile. It will then inspect each member record in an FNR to determine which members are missing in the current file. The method of determining missing members is different for Full Population Files vs. Changes Only Files as noted below.

1. A member record that is missing for the current file will be created into the current file with a "Removed From File" status.
2. Only "Active", successfully processed member records will be considered for evaluation.
   1. If a member has records, but no record was ever successfully processed, the member is not considered as ever being processed.
   2. If a member has records, but all of them have been reversed, the member is not considered as ever being processed.
3. If more than one member is missing from an FNR, a single record will be created for each missing member. The process order is determined by looking at the process order for the last record for the missing member.
   1. Only one member record will be created as "Removed from File" for each missing member. For example, if the previous FNR had 2 records for the same dependent member, only the one missing record will be created.
4. For a Changes Only File, no members will be calculated as missing if the entire sponsor (FNR) is missing from the current file.
5. For a Full Population File, if an entire Sponsor (FNR) is missing, then an entire FNR will be created for the current file. A member record will be created for each member that was present in the last FNR.
   1. Only one record for each missing member will be created in this case. If the previous FNR had 2 records for the same member, only one missing record will be created.

Preprocess All Records

A file enters pre-processing when the "Process" API Call is made from the OIPA Bridge. At that time, the records are all staged in the database, ready to be picked up for processing in the OIPA Grid. Pre-Processing for records is defined through the Intake Profile Definition, Intake Profile, and Data Intake Transaction. The phases of processing individual records are described in detail subsequent this section. This section will only provide a summary review of record level processing.

1. Records are processed in record groups according to the Family Neutral Record they belong to. Records are processed according to the order in which they were submitted to OIPA by the insurance carrier's file receiving system.
2. Each record has information pertaining to the employee / primary participant / sponsor, or one of the employee's participants.
3. The record is exercised against the field validations defined in the Intake Profile and Intake Profile Definition. Errors and warnings are generated at this time, and made available for processing.
4. Changes are calculated for the record. Changes can be calculated against the prior record for the member or the system data for the member. How changes are calculated will be defined in the rules configured in the Rules Palette.
5. Math configured in the Intake Record Transaction is run for the record, and is provided the calculated changes, field warnings and errors, record data, and intake profile fields. Here, activities will typically be generated to create an activity sequence process that is appropriate to impart the changes for the record in the system.
6. Attached Business Rules are executed for the record.
   1. An example of an attached business rule is Validate Expressions, where expressions are evaluated to test different conditions in the record and information calculated in Math. The outcome of Validate Expressions could result in failing the record.
7. The results of the record are stored in the database, including the activities that were calculated. The activities are not processed at this time; they are executed after threshold processing.

Intake File Transaction Threshold Processing

A file enters threshold processing after all of the records for the file have completed pre-processing. At this time, activities have been created, but not executed, for all of the records. Record information, statuses, changes, warnings, and other information are stored in OIPA and available for reporting and in the user interface. The following requirements apply to Threshold Processing:

1. Threshold processing executes the file transaction in order to calculate statistics. This can include queries to generate counts and other metrics.
   1. For example, the number of auto-cancels can be calculated by running a SQL query in the math section of the transaction to find all records that have been marked as auto-cancel.
2. The statistics that are generated in the Math section of the transaction will be captured and stored in the system. Statistics will be able to be copied to file level fields using the CopyTos attached business rule.
3. A Validate Expressions business rule can be attached to the file transaction to test various variables that are calculated in the Math section in order to determine if a file is valid able to be processed.
   1. For example, the number of auto-cancels can be tested against an Auto-Cancel threshold that is configured in the Intake Profile. If the number of auto-cancels exceeds the threshold, the error will be stored and the records will not be processed further.
4. If a file passes the Validate Expressions, then the activities that are generated for the records in the file are executed. The status of the file moves to Executing.
5. If a file fails the Validate Expressions, no activities will be run in the system for the file. The status of the file moves to a Business Error status.
   1. The file is not available for reversal processing.
   2. The file and all records should not be considered for future processing. For example, they should not be used for purposes of changes calculation or calculating missing records.

Execute Records

After a file passes threshold processing and is considered valid for execution, all of the activities for all of the records that were generated as part of pre-processing are run. Details on how each record's activities are executed are detailed in the Phases of Data Intake Record Processing section below. When a file finishes execution for all activities, the status of the file moves into a "Complete" status.